test: print the .so under test, and name what PGC_SKIP_BUILD actually skips (#508 follow-up) - #513

…cts (#537)

Adversarial review by @ChronicallyJD, all three findings reproduced here before
being fixed. The first should have blocked the merge and did.

1. THE FIX WAS REMOVABLE WITHOUT A RED. Measured, not reasoned:

     delete the pgc_start_log_report call from pgc_setup  -> 70 checks, PASSED
     revert the summary path to a hardcoded pattern       -> 70 checks, PASSED
     assert a squatter unconditionally                    -> FAILED, 2 checks

   The 16 checks fed the three functions fixtures and proved their arithmetic.
   Nothing asserted the failure path calls any of them, so the entire
   contribution of this branch could be deleted and the suite still reported
   green. That is the same gap #538 found in #532's bench guards -- the same
   mistake, twice, the second time inside a fix for an issue about a message
   asserting something the code has not established.

   Six call-site checks now, over source text, which is the weaker kind and is
   labelled as such. The failure path needs a cluster that will not start, which
   this suite cannot stand up; a weak check on the call site beats none. Both
   greps are premised on the path still existing, or they approve nothing.

   Rows 1 and 2 above are now red. Row 3 already was.

2. pgc_fatal_pattern's docstring claimed "one definition, used by both the
   start-failure path and the summary path". pgc_start_log_report never called
   it; it hardcoded FATAL:|PANIC:. So the comment asserting the drift had been
   fixed was itself untrue, committed in the fix for #537.

   The divergence is right and argued below it. There are now two NAMED patterns,
   pgc_fatal_pattern and pgc_start_fatal_pattern, so the difference is greppable
   rather than two literals in two places, and a check asserts each path asks its
   own.

3. _sawforeign was sticky: set on any attempt, never cleared. One squatter on
   attempt 1 followed by seven genuine start failures printed the squatter
   verdict for all eight -- #537's own defect narrowed rather than removed, and
   reachable, since escaping a port collision is what the retry loop is for.

   It is a count now, with three cases: none, all, and the mixed one that a flag
   cannot express. The mixed case has its own check and fails when the old
   any-nonzero behaviour is restored.

One check of my own was wrong rather than the code: a grep for the inline verdict
matched two unrelated lines about the previously installed .so (#513). Tightened
to the start-failure text, with the reason recorded, since that is the same
prefix-matching trap this suite already guards for suite names.

harness_selftest 70 checks to 78. End-to-end re-verified with a genuinely broken
.so after the pattern change. Gate: PG17 assert 132 ran PASS, PG19 assert 137 ran
with only temporal, btree_gist absent from this container, identical on main.

Refs #537

…own rule (#545)

Review by @ChronicallyJD. Every one is the file not meeting the standard it
states, which is the only kind worth reporting in a change about how to argue.

CITED THE REMEDY AS THE DEFECT. The removal bullet listed #538 as a change that
shipped deletable. #538 is the change that CAUGHT it; the one that shipped
deletable was #532. Corrected, with #538 named as the catcher so the pair is
still findable.

THE PERSON-CLAIM SURVIVED ONE PARAGRAPH DOWN. I cut "Both authors had read this
line" from the removal bullet, said so in the commit message, and left "it
stayed quiet for two people writing fixes" in the trigger bullet, which asserts
the same unestablished thing in different words and is wrong the same way: both
changes were one author's. It now reads "for both changes above" and claims
nothing about anyone.

This is the finding worth keeping. A corrected sentence is not a corrected
belief, and the second instance is where you stop looking because the first one
felt like the fix. That is the same shape as the trigger bullet itself: knowing
the rule is not what makes it fire.

THE ONE UNCITED CLAIM. The loose-grep example carried no issue number while
#532, #537, #487 and zonemap_cost all do, in a section about not making
unverifiable statements. Now cites #537, and #513 for the message it collided
with.

Refs #545

…st (#545)

Proposed by @ChronicallyJD, and their wording rather than mine.

I had offered "a corrected sentence is not a corrected belief, and the second
instance is where you stop looking because the first one felt like the fix". True
as a diagnosis, and wrong as a bullet: its operative content is "notice that the
correction felt like completion", which is an instruction to notice harder. It
cannot be checked and it cannot fire, and it would have sat one paragraph below
"Consult it more carefully is not a fix" -- this section failing its own standard
a fourth time, in the sentence added to record the third.

The mechanical form earns its place: search for the same claim elsewhere, grep
for the phrasing you just removed. Ten seconds, names the tool, fails visibly
when skipped. Same properties as "can I delete this change and still be green".

The bullet then caught a fourth instance of its own class before this commit
landed, which is why the example in it is two failures rather than one. Verifying
every issue number in the added text -- which is what the bullet demands -- found
that the loose-grep example cited #513 for a message introduced by #508. The
previous commit had corrected exactly this defect, #538 cited where #532 belonged,
four lines away. The first correction felt like completion, again, in the edit
that recorded the first correction feeling like completion.

The psychology stays here in the history, where the story of how it happened is
findable, and the bullet carries only the part a reader can execute.

Refs #545